Long Press to delete entire word - #2556

Nice work – and a note in your favour first: unlike the other two delete-word PRs (#2499, #2329), this one reuses HeliBoard's own mConnection.getWordRangeAtCursor(...) instead of a locale-bound BreakIterator, which is the direction the maintainer asked for in #2499. I read through the diff and wanted to flag a few things:

1. Translations (blocking per guidelines). The PR modifies ~50 values-*/strings.xml files. Per CONTRIBUTING.md: "Updating translations in a PR will not be accepted, as it may cause conflicts with Weblate." Only the new English strings in values/strings.xml should stay; the other locales go through Weblate.

2. The onLongPressed DELETE_WORD block never runs for the default delete key. onLongPressed() is only reached from startLongPressTimer(), which returns early unless key.isLongPressEnabled() (ACTION_FLAGS_ENABLE_LONG_PRESS). The default delete key has no popup keys, so it gets ACTION_FLAGS_IS_REPEATABLE instead (Key.java ~1189-1194) and never ENABLE_LONG_PRESS. So the whole feature actually runs through onKeyRepeat, and the onLongPressed branch (including mWordDeleteTickCounter = 0 and the "fire the first word instantly") is dead code for the normal delete key.

3. mWordDeleteTickCounter is therefore never reset. Since the only reset lives in the dead onLongPressed path, and PointerTracker instances are pooled/reused, the counter keeps accumulating across delete presses. The result is that the delay before the first word deletion varies from hold to hold (leftover counter modulo threshold), which makes the feature feel inconsistent. Resetting it in startRepeatKey/onKeyRepeat when repeatCount indicates the start of a new repeat would make timing deterministic.

4. Hardcoded 50 ms tick. Math.round(mKeyLongpressTimeout / 50f) assumes the repeat interval is 50 ms. That value comes from config_key_repeat_interval (config-common.xml) and is exposed as sParams.mKeyRepeatInterval — better to use that so it stays correct if the interval changes.

5. Possibly-unused imports. LatinIME.java gains StringUtilsKt and TextRange imports, but handleDeleteWordEvent lives in InputLogic.java; those two imports look unused in LatinIME.

6. DELETE_WORD (-8) in custom layouts. You uncomment DELETE_WORD = -8 in KeyCode.kt and add it to Constants.printableCode, but it isn't in checkAndConvertCode()'s supported list, so it can't be assigned in custom layouts/toolbar keys. That's fine if intentional — just worth stating whether the code is meant to be user-assignable or purely internal to the delete-hold gesture.

None of this is a showstopper for the idea; (2)+(3) are the ones that most affect real-world behaviour. Thanks for tackling this!

I'll tackle these issues and get to you again